1. Technical Field
The present invention relates in general to improved heap management and, in particular, to improved efficiency of allocation of a large object within a heap. Still more particularly, the present invention relates to facilitating efficient non-contiguous allocation of a large object which is too large to fit within a contiguous free space within a Java heap by chunking the large object into multiple pieces at a broker layer.
2. Description of the Related Art
The Internet provides protocols that support one layer of connectivity between multiple computer systems distributed across multiple networks. However, while the Internet supports one layer of connectivity, to connect the many diverse platforms operating via the Internet, additional layers of connectivity are required. In particular, to increase business productivity, many companies now face the problem of enabling additional layers of connectivity so that heterogeneous and geographically distributed systems can communicate. On another level, companies face the problem of supporting both information and processes across an enterprise's network of diverse systems and technologies.
One solution to the problem of supporting distribution of information and processes across diverse systems is through the implementation of a hub and spoke type of infrastructure. In a hub and spoke infrastructure, a broker or other central infrastructure acts as a hub for straddling existing and new diverse systems and technologies to unite dissimilar data sources and applications.
In general, in a hub and spoke infrastructure, the hub receives data from many spokes, distributes the data among processes executing within the hub, and then returns the results to the spokes. The hub includes adapters that enable the hub to communicate with spokes implementing a diversity of protocols and data types. The adapters in the hub may translate, map, or reformat data so that the processes within the hub can understand the data received from the spokes. The hub includes multiple business processes to which the adapters pass data for processing. Once the business process complete execution, the hub may translate the resulting data so that the spoke receiving a result can understand the data.
In one example, the components within the hub that perform the receiving, the distributing, and the returning may be written in Java (Java is a registered trademark of Sun Microsystems, Inc. in the United States and other countries). Java based components interact with a Java Virtual Machine (JVM) (JVM is a registered trademark of Sun Microsystems, Inc. in the United States and other countries), which acts as the operating system for Java based applications. The Java Virtual Machine (JVM) runs atop the native operating system of the server or other computer system. The JVM accesses memory through the native operating system, and, in particular, requests the allocation of a Java heap, which is a contiguous portion of memory dedicated for use by the JVM. The JVM then receives allocation requests from the Java based components of the hub and controls allocation of the objects within the Java heap.
A common problem with JVM performance is that the JVM must locate a contiguous free space within the Java heap to allocate an object; if the JVM cannot locate a contiguous free space of sufficient size, then an Out of Memory error is returned to the Java component. This problem of locating contiguous free space of sufficient size in the Java heap increases as the size of allocation requests increases. In particular, as the JVM allocates and then deallocates objects within the Java heap, the free space in the Java heap becomes fragmented over time, leading to the return of Out of Memory errors even when the total free space in the Java heap is large enough for an object allocation, because there is no contiguous free space large enough for a particular object allocation. For example, because of fragmentation, a Java heap may include 100 MB total of free space, however, the largest contiguous free space is only 1 MB, leading to the return of an Out of Memory error when the JVM attempts to allocate an object greater than 1 MB.
Because of the problem with the JVM returning Out of Memory errors when sufficient contiguous free space is not available for an allocation, a common problem within a Java component based hub, such as the IBM WebSphere Interchange Server (IBM and WebSphere are registered trademarks of International Business Machines Corporation), is that as the Java heap becomes fragmented, any data object passing through the hub that exceeds the size of the largest average free space within the Java heap, will cause the hub to stall. In particular, within the hub and spoke architecture implemented through the IBM WebSphere Interchange Server, it is common for the hub and spokes to pass batches of data in the form of a data entity, known as a business object. Business objects may include arrays of data formatted to match a business object definition known by the hub and a spoke. Business objects that include the data needed for batch process handling may grow large as the data is accumulated at the spoke into a business object. In addition, as each Java component within the hub handles a business object, each Java component may request additional allocations of the business object from the JVM within the Java heap and may increase the size of the business object during translations or clone multiple copies of the business object for distribution to multiple business processes within the hub. Thus, for example, a business object pulled off the transport layer of the hub that appears 10 MB in size may result in the allocation of many larger Java objects in the Java heap, such as allocations of 30 MB of contiguous space in the Java heap, as the business object flows through the Java components of the hub. In the example, if the JVM is unable to locate more than 10 MB of free space on the Java heap on average, then the JVM will return an Out of Error message that stalls the first Java component requesting allocation of the business object as a Java object within the Java heap. Thus, Out of Error messages received by Java components within the hub are a problem because the Out of Error messages delay the hub's handling of business objects and indicate the hub's inability to handle business transactions requiring transfers of batches of data larger than a typical maximum contiguous free space size.
Both the JVM and the Java components within a hub may include tuning parameters to aid a network administrator in reducing the frequency at which Out of Memory errors occur; however, adjustment of these tuning parameters only effectively adjusts the average maximum size of contiguous free space within the JVM and does not solve the problem of how to handle business objects larger than the maximum contiguous free space when the total available free space is still greater than the size of the business object. For example, a hub administrator may increase the size of the Java heap in an attempt to reduce the frequency at which Out of Memory errors occur because more total heap space is available, however each operating system on top of which the JVM runs limits the maximum Java heap size and increasing the Java heap size does not change the resulting fragmentation of free space within the Java heap. In another example, a hub administrator may set the rate at which business objects can flow through the Java components of the hub to reduce the number of business objects concurrently allocated in the Java heap, however, setting the flow rate of a business object through the hub does not change the fact that the JVM may not be able to locate sufficient contiguous free space within the Java heap for allocation of a business object exceeding the maximum contiguous free space.
Therefore, in view of the foregoing, there is a need for a method, system, and program for enabling a Java based broker that facilitates distribution of data entities to business processes to efficiently allocate data entities, such as business objects, exceeding the maximum contiguous free space available in the Java heap, particularly when the total free space available in the Java heap exceeds the size of the data entity. In particular, it would be advantageous to provide a method, system, and program for enabling allocation of large objects among non-contiguous free spaces to reduce fragmentation of the Java heap, without changing the manner in which the JVM allocates objects and in a manner that is transparent to the spokes and to other Java components within the hub.